Denial of service (DoS) attacks cause service disruptions when limited server resources are allocated to the attackers instead of to legitimate users. A distributed denial of service (DDoS) attack launches a coordinated DoS attack toward the victim from geographically diverse Internet nodes. The attacking machines are usually compromised zombie machines controlled by remote masters. The resources typically under attack include link bandwidth, server memory and CPU time. Distributed DoS attacks are more potent because of the aggregate effects of converging traffic, especially when the attackers have inside knowledge of the network topology. “TCP SYN flood,” “smurf IP ping,” and bandwidth attacks on root name servers are all examples of such attacks which have been previously deployed. (Each of these attacks will be familiar to those skilled in the art.) However, it has been reported that there have in fact been far more of such attacks than have been previously known.
There are numerous approaches to improve server operating systems to resist resource exhaustion. Some have considered better network protocol design principles to protect servers from attacks on stateful handshake protocols (familiar to those of ordinary skill in the art). IP trace back is another well-known approach—it is a network-wide coordinated effort to follow the offending packets back to their originators. However, such an approach obviously requires network-wide cooperation and coordination.
In fact, many previous attacks could have been prevented entirely if ingress filtering were deployed Internet wide or if a source address validation protocol were widely used. And, although many victims of recent bandwidth attacks were flooded by unspoofed ICMP reply packets, the corresponding ICMP echo requests were all spoofed. (As is well-known to those of ordinary skill in the art, a “spoofed” packet is one in which the source address is fictitious or fallacious.) Heuristic-based bandwidth attack detection by signatures have also been considered for monitoring and network congestion control. For example, one proposed approach classifies incoming packets into UDP, TCP, TCP SYN, and CGI categories (each of which is fully familiar to one of ordinary skill in the art), and then enforces class-based rate control and weighted fair queuing.
Moreover, DDoS attack tools may tend to mutate and evolve over time. With wider deployment of egress filtering, for example, attackers will undoubtedly exploit doors that are most likely to be left open (e.g., TCP, DNS). Attack signatures may change or disappear to evade detection. Thus, it is likely that sophisticated future attacks will become almost indistinguishable from legitimate ones. A filtering-based approach to the problem alone is, therefore, not only inefficient but also insufficient. Many false positives will force researchers to go back to the drawing board for new heuristics.
One particular type of DDoS attack on a TCP server can be launched by continuously creating new TCP connections with the targeted server until it runs out of memory and is therefore unable to accept service requests from legitimate users. (As is familiar to those of ordinary skill in the art, TCP is the well-known Department of Defense standard Transmission Control Protocol—see, e.g., “Transmission Control Protocol,” prepared for Defense Advanced Research Projects Agency by Information Sciences Institute, J. Postel, editor, Request for Comments (RFC) 793, September, 1981, “www.faqs.org/rfcs/rfc793.html.” RFC 793 is hereby incorporated by reference as if fully set forth herein.) The deleterious effect of such an attack results from the fact that each established TCP connection necessarily creates a state on the TCP server, and therefore, the amount of allocated memory for storing these states is proportional to the total number of open connections. Such an attack has heretofore been named “Naptha,” and is known as such by those skilled in the art, but it will be more generally referred to herein as a “TCP stateless hog” attack.
There is no known defense against TCP stateless hog (i.e., Naptha) attacks. However, a TCP keep-alive mechanism is well known to those of ordinary skill in the art as an official specification for the Internet community—see, e.g., “Requirements for Internet Hosts—Communication Layers,” Internet Engineering Task Force, R. Braden, editor, Network Working Group, Request for Comments (RFC) 1122, section 4.2.3.6, October, 1989, “www.faqs.org/rfcs/rfc1122.html.” (Section 4.2.3.6 of RFC 1122 is hereby incorporated by reference as if fully set forth herein.) This keep-alive mechanism may advantageously be invoked in server applications that might otherwise hang indefinitely and consume resources unnecessarily if a client crashes or aborts a connection during a network failure. Although such a keep-alive mechanism could in principle be used to alleviate the TCP server during an attack in-progress, it can easily be defeated without much cost for the attacker.